4.3.1. After my initial test on two computers I modified other aspects (the application log entries) and changed some of the program operation. That, as it turns out was a problem. I spent most of the morning trying to get the program to function again. After a little time I was able to get it back into a running state. To help with the trouble shooting here is one of the errors I was getting. I fixed a problem I was having with IP addresses in the program. I initially used fixed addresses, but I wanted flexibility. So I came up with a way to use the IP text box. In my older version I had the addresses hard coded to help with troubleshooting. After I got that straight the program worked as expected.
4.3.2. On of the features I added to the program was the event log writer. Here is one of the messages that I encountered when trying to get the program running. I used a made up event id (1086) because I couldn’t find any error messages that matched my program errors. I was able to use custom text to display the error message though.
4.3.3. When you open up the log viewer (I made an MMC to look at the logs) the error message is displayed. I also use an information message stating that the application started.
4.3.4. Once I got the IP issues worked out I was able to run the application and have a conversation. In trying to not have so much space in the conversation area, I ended up having messages show up on the same line. This is a cosmetic issue and can be easily fixed. My intent here is to demonstrate the function of the program.
4.3.5. The program sends an encrypted file (EncryptFile.txt) and runs a decryption algorithm on it to decrypt (DecFuleData.txt) it at the receiving end.
4.3.6. So what’s under the hood? Here is how the program breaks down. The program starts out by declaring three main objects, server (which handles all encryption), obj (which receives the files), and objSend (which sends the files). When the form is created it adds a delegate from the receive class so it can be notified of a file receipt. It also sets the receiving directory for incoming files. Then it sets the computer name in the title bar and writes a log file entry that the program started.
4.3.7. When the form loads it disables the send button to force the user to use the connect button. It also initializes the server class. The LogWritter method adds entries to the Windows application event log. I had problems with this portion because of registry permissions. With the information from David’s program I could make a registry update to create an event key if one doesn’t exist. But to demonstrate the capability I manually added the application name to the registry and check to see if it exists. If it does I write a log entry, otherwise I skip it all together.
4.3.8. Below is a screen collage of the registry where the secure chat program has an entry in the event log tree.
4.3.9. The next portion of the program starts a new thread for the receive object. When the user clicks the connect button the program verifies that there is a value for the IP address and then starts the channel for listening. It also enables the send command button and sets the focus to the send message text box.
4.3.10. The send command makes sure there is a message to be sent and then formats it by putting the selected user name and the message they typed. Once the message is formatted it gets encrypted with the server object. If the encryption is successful then the message is displayed in the conversation box and the send file method is called.
4.3.11. When the download is complete the download delegate (DownLoadComplete) is fired and the program tries to decrypt the received message. If successful it updates the currentMessage variable. When this is done a timer event checks the status of current message and if it is not blank it adds it to the conversation message box. I did this because the delegate runs in the message thread and is independent of the main program. This method bridges the gap between to two processes.
4.3.12. The FTReceive class is what listens to the socket for incoming traffic. Once received it sends a delegate event to the main program indicating completion. The class has a few main members thatmake everything happen. The delegate is tied to the dlcomp variable, the ipEnd and sock variables are used for the IP connection to receive the file. The constructor sets the object in a ready to receive mode.
4.3.13. The DownLoadStatus is what triggers the delegate if its state changes.
4.3.14. The StartServer is run on an independent thread and listens on the socket for a file to download.
4.3.15. The FTSend class has one primary member, the conIP. I use this to interface with the main program so you can adjust the IP address.
4.3.16. The send file method is the workhorse of the application. It decodes the path to find the file name and path and then converts the file to an ASCII bit array. If the is over a certain size it generates an error. This program doesn’t have this issue. Then the file is sent through a BIT converter and sent to a TCP stream and transmitted.
4.3.17. The server class was my first attempt to get a client server application developed. It turned into a single client application, however I thought it would be nice to keep the .dll concept to demonstrate some complexity and working with libraries. This started out by trying to send and receive messages. When I was having problems with my connection implementation I finally abandoned trying to do these connections from here.
4.3.18. The Capitalize method was part of the explanation for the client server model. It worked well enough.
4.3.19. The encrypt method takes a string from the calling program and then calls the actual encryption method with all of the appropriate parameters. I had issues with a previous version with the decryption method. I need the generated encryption key and didn’t want the complexity of sending two file. So I found a different encryption method that would encrypt and decrypt with the same parameters.
4.3.20. The decrypt method looks for an encrypted file and reads the contents. Once the file data is read it calls the decryption method with the same parameters as the encryption method.
4.3.21. The actual encryption method goes through a series of encoding steps that it applies to the data that is passed to it.
4.3.22. Once it is complete it writes the end result to a file.
4.3.23. The decrypt method takes the encrypted data and converts it to readable text.
Secure Chat Application
4.3. Les's Program
4.3.1. After my initial test on two computers I modified other aspects (the application log entries) and changed some of the program operation. That, as it turns out was a problem. I spent most of the morning trying to get the program to function again. After a little time I was able to get it back into a running state. To help with the trouble shooting here is one of the errors I was getting. I fixed a problem I was having with IP addresses in the program. I initially used fixed addresses, but I wanted flexibility. So I came up with a way to use the IP text box. In my older version I had the addresses hard coded to help with troubleshooting. After I got that straight the program worked as expected.
4.3.2. On of the features I added to the program was the event log writer. Here is one of the messages that I encountered when trying to get the program running. I used a made up event id (1086) because I couldn’t find any error messages that matched my program errors. I was able to use custom text to display the error message though.
4.3.3. When you open up the log viewer (I made an MMC to look at the logs) the error message is displayed. I also use an information message stating that the application started.
4.3.4. Once I got the IP issues worked out I was able to run the application and have a conversation. In trying to not have so much space in the conversation area, I ended up having messages show up on the same line. This is a cosmetic issue and can be easily fixed. My intent here is to demonstrate the function of the program.
4.3.5. The program sends an encrypted file (EncryptFile.txt) and runs a decryption algorithm on it to decrypt (DecFuleData.txt) it at the receiving end.
4.3.6. So what’s under the hood? Here is how the program breaks down. The program starts out by declaring three main objects, server (which handles all encryption), obj (which receives the files), and objSend (which sends the files). When the form is created it adds a delegate from the receive class so it can be notified of a file receipt. It also sets the receiving directory for incoming files. Then it sets the computer name in the title bar and writes a log file entry that the program started.
4.3.7. When the form loads it disables the send button to force the user to use the connect button. It also initializes the server class. The LogWritter method adds entries to the Windows application event log. I had problems with this portion because of registry permissions. With the information from David’s program I could make a registry update to create an event key if one doesn’t exist. But to demonstrate the capability I manually added the application name to the registry and check to see if it exists. If it does I write a log entry, otherwise I skip it all together.
4.3.8. Below is a screen collage of the registry where the secure chat program has an entry in the event log tree.
4.3.9. The next portion of the program starts a new thread for the receive object. When the user clicks the connect button the program verifies that there is a value for the IP address and then starts the channel for listening. It also enables the send command button and sets the focus to the send message text box.
4.3.10. The send command makes sure there is a message to be sent and then formats it by putting the selected user name and the message they typed. Once the message is formatted it gets encrypted with the server object. If the encryption is successful then the message is displayed in the conversation box and the send file method is called.
4.3.11. When the download is complete the download delegate (DownLoadComplete) is fired and the program tries to decrypt the received message. If successful it updates the currentMessage variable. When this is done a timer event checks the status of current message and if it is not blank it adds it to the conversation message box. I did this because the delegate runs in the message thread and is independent of the main program. This method bridges the gap between to two processes.
4.3.12. The FTReceive class is what listens to the socket for incoming traffic. Once received it sends a delegate event to the main program indicating completion. The class has a few main members thatmake everything happen. The delegate is tied to the dlcomp variable, the ipEnd and sock variables are used for the IP connection to receive the file. The constructor sets the object in a ready to receive mode.
4.3.13. The DownLoadStatus is what triggers the delegate if its state changes.
4.3.14. The StartServer is run on an independent thread and listens on the socket for a file to download.
4.3.15. The FTSend class has one primary member, the conIP. I use this to interface with the main program so you can adjust the IP address.
4.3.16. The send file method is the workhorse of the application. It decodes the path to find the file name and path and then converts the file to an ASCII bit array. If the is over a certain size it generates an error. This program doesn’t have this issue. Then the file is sent through a BIT converter and sent to a TCP stream and transmitted.
4.3.17. The server class was my first attempt to get a client server application developed. It turned into a single client application, however I thought it would be nice to keep the .dll concept to demonstrate some complexity and working with libraries. This started out by trying to send and receive messages. When I was having problems with my connection implementation I finally abandoned trying to do these connections from here.
4.3.18. The Capitalize method was part of the explanation for the client server model. It worked well enough.
4.3.19. The encrypt method takes a string from the calling program and then calls the actual encryption method with all of the appropriate parameters. I had issues with a previous version with the decryption method. I need the generated encryption key and didn’t want the complexity of sending two file. So I found a different encryption method that would encrypt and decrypt with the same parameters.
4.3.20. The decrypt method looks for an encrypted file and reads the contents. Once the file data is read it calls the decryption method with the same parameters as the encryption method.
4.3.21. The actual encryption method goes through a series of encoding steps that it applies to the data that is passed to it.
4.3.22. Once it is complete it writes the end result to a file.
4.3.23. The decrypt method takes the encrypted data and converts it to readable text.
4.3.24. When complete it writes it to a file.
4.3.25. That completes Les’s Secure Chat program.
Project Home Next Section